The technology and techniques described in this section are considered by the patent applicant to be useable in conjunction with the present invention, but they may not necessarily have been previously conceived, pursued and/or published. Therefore, unless otherwise explicitly indicated, nothing described in this section is prior art to the claims in this application. In particular, there is no admission that anything is prior art merely by virtue of its inclusion within this section.
In larger computer networks, the task of granting service access to devices (remote or local) is frequently nowadays controlled centrally, by means of an AAA (Authentication, Authorization and Accounting) server, also known as an Access Control Server. This typically uses a standard protocol known as RADIUS (Remote Access Dial In User Service). An AAA server supporting RADIUS, as its name suggests, typically provides a range of functionality including authentication, service request authorization and also the provision of logon and logoff times and other session data for accounting purposes.
A challenge is that customers naturally desire to control and provision user sessions on network access devices with a common tool and policy framework i.e. a single AAA server infrastructure. This results in the requirement for the AAA server to establish the service being requested by the end user and on which type of network access device (different devices may offer the same service e.g. but require different provisioning for that service). In the RADIUS protocol, however, there is currently no way for the end user or the network access device to indicate what type of device is involved (router, WLAN AP, Ethernet switch, VPN concentrator, firewall etc.), what Operating System and version the device is running or to adequately describe the type of service that is being requested (Dial access, VPN, WLAN access, LAN access, VOIP access, firewall access, etc).
One approach to this problem that has been used in the past is to require network administrators to configure the AAA server with the explicit knowledge of what each network access device (or collections of devices) requires of it. This solution is, however, unacceptable since it increases the burden on the AAA administrator and scalability breaks down at relatively small numbers of devices (eg hundreds of devices). Additionally, this approach only works for single-service devices (eg where a single Service is being provided by a device as described by its IP address).
Present approaches include the capability within AAA servers to define multiple rules to handle service requests, along with the associated IP address maintenance required when large numbers of network devices are in use. While such approaches can be very effective in the hands of skilled network administrators, they do require specialized skills, and it is not always easy in practice to handle complex set-ups in which IP clashes may be expected. There can also be difficulties in dealing with multi service (eg so-called ‘multi-blade’) devices, for example some firewalls, VPN concentrators and Ethernet switches, where there may be several different devices which all have the same IP address as perceived by the AAA server.
The most modern systems do allow for service provisioning to be provided at some other levels, and not just by IP address. For example, rules can be defined to set one type of service for a VPN, another for a dial-up modem and so on. Within each of these, IP address ranges may be defined. As an example of this, reference may be made to a document entitled “Cisco Secure Access Control Server for Windows” which is available at the time of writing as file products_user_guide_chapter09186a0080184955.html#104542 in the folder en/US/products/sw/secursw/ps2086 within the domain www.cisco.com on the World Wide Web; and in particular to the section headed “AAA Client Configuration”.
Unfortunately, the ubiquitous RADIUS protocol is inadequate when dealing with this level of complexity. When RADIUS was designed in the early 1990s it was specifically designed, as its name clearly implies, to solve the specific problem of dial-in user access. RADIUS was a single service provided for one type of network access device, a dial up router, to a user. Whilst some capabilities were built into RADIUS to provide some granularity of description of service type (e.g., attribute 6, ‘Service-Type’), the options provided by the RADIUS standard are relevant to dial access service control (with the exception of administrative access control that has largely been supplanted in the Cisco sphere by the more suitable TACACS+protocol). In the single-service supported world of dial access, deciding how to provision a user session was generally simple, as even in a multi vendor environment all the access devices were providing an homogeneous service (ie dial up routing). This is not the case today.
One approach, of course, would be to abandon the use of RADIUS entirely, and instead make use of some rather more feature-rich protocol such as TACACS+ or DIAMETER. But those protocols would by no means supply a complete solution and, in any event, the use of RADIUS is currently so widespread and well-understood that there would be substantial practical difficulties in attempting to supplant it entirely within a short to medium timescale.